Online Social Network Data Placement over Clouds

Internet services today are often deployed and operated in data centers and clouds; users access and use the services by connecting to such data centers from their computing devices. For availability, fault tolerance, and proximities to users at diverse regions, a service provider often needs to run the service at multiple data centers or clouds that are distributed at different geographic locations, while aiming to achieve many system objectives, e.g., a service provider may want to reduce the money spent in using cloud resources, provide satisfactory service quality, data availability to users, limit the carbon footprint of the service, and so on. Inside a data center, a service provider is also concerned about some system objectives, e.g., running a service across servers may need to diminish the traffic that passes the oversubscribed core of the data center network. A variety of system objectives can be addressed by carefully splitting and placing data at different clouds or servers. For instance, different clouds may charge different prices and emit different amounts of carbon for executing the same workload; they also have different proximities to users. Different servers inside a data center could reside at different positions in the data center network, where the traffic between servers at a common rack does not affect the network core but the traffic between servers at different racks may do. It is important for a service provider to make right decisions about where to place users’ data over a group of clouds or servers, as data placement influences system objectives. This thesis investigates the data placement problem for the Online Social Network (OSN) service, one of the most popular Internet services nowadays. Data placement for the OSN service has many challenges. First of all, users’ data are interconnected. Ideally, the data of a user and the data of her friend should be co-located at the same cloud or server so that the user can access all the required data at a single site, saving any possible additional delay and traffic going across cloud or sever boundaries. Secondly, the master-slave replication complicates the data placement. A user may have a master replica that accepts both read and write operations and several slave replicas that only accept read operations; master and slave contribute differently to different system objectives and the best locations to place them can also be different. Thirdly, if multiple system objectives are considered, they are often intertwined, contradictory, and cannot be optimized simultaneously. Saving expense needs data to be placed at cheap clouds; reducing carbon prefers data to be placed at clouds with less carbon